3D Coding TAT - Final Words
0: The Crystal Fool
Here are some predictions about the kind of abilitites which the next generation of 3d engine might have and some of the common sense rules which unfortunately some new games still ignore.
1. Curved polygons.
No more breeze block people or creatures. Instead of simply boosting the
polygon count like most engines do these days perhaps Spline or Voxel based
rendering methods can be used. This could allow smooth, organic looking
items to be modelled with a modest number of control points using only a
fraction of today's vertex counts. I think Blade Runner and Estactica were
some of the first games to tackle the block-head problem. This curve
interpolation would allow very large models to remain smooth looking when
viewed from very close range.
2. Dynamic game worlds.
Flexibility in the game engine allowing trees, walls, even buildings
themselves to be demolished or created. The very static, traditional BSP
type mapping and other similar methods really need to be greatly overhauled
with far more REAL-TIME processing and structural-manipulation done by the
CPU during play rather than before hand. This would require some new, fast
techniques to be developed, so plenty of room for talented binary inventors
here.
3. Jelly scenary.
Items such as trees or other flimsy objects behave and respond to impacts
or environmental forces, such as wind, tides or other non-player creatures.
Things such as weather, natural or artifical events should be possible
using 'local knowledge' of the player's current surroundings.
4. Better details.
The level of detailing will hopefully increase in line with level size
rather than simply producing vast, empty rooms for the player to run
through.
5. More interaction.
Yeah, more of this within the levels instead of the ancient "let's put a
switch every 3 miles" method of game design. We have all played in high-tec
environments but all seem to be reduced to pressing buttons, collecting
keys or jumping across vast canyons. If an object is drawn on the screen
then why can't I interact with it, pick it up and use it?
6. Greater freedom.
Most games tend to take you by the hand and guide you through the level.
The game designers have forced us into a narrow and linear way of playing.
Which is good from a programming point of view as it means there are only a
few possible routes and sequences in which things can be done. But from an
adverture point it usually sux. There should always be an alternative way
of completing a task, using a different object or by taking another route.
Hopefully you can see that there is still a vast amount of new techniques which can be introduced to the novelty eager players out there. Don't get bogged down by counting polygons or creating a photo-realistic renderer as most players won't notice these things only other programmers will. The player is usually far more impressed by new stuff, new toys to have fun with and new ways to interact with the level.
There is such a rich and already well known resource for future 3d game ideas. It's the REAL-WORLD! So take a good look around, see what looks like fun or better still, dangerous and try to present it to the player in an easy to understand manner. It is very easy to just look at other games for ideas but most of the time you will be cloning a clone, so look at science, biology and old sci-fi films. I have seen some state-of-the-art demo effects in 30-50 year old sci-fi film titles! Things like motion blurring, text blends and plasma-like bobs can be found in the opening title for the classic "The Day Of The Triffids".
There is only one rule for games programming:
"If it is still fun for the programmer to play after months of development, then it is usually fun for the player too".
I have witnessed plenty of games done by 9-to-5 programmers who just wanted to meet the deadlines and get paid. Their sole interest in the game was to finish it and get it out of their sight. Sadly most companies tend to favour these individuals as they are often like the managers themselves, but their 'video games' talent is often lacking the enthusiasm which turns an average game into a really playable game.
I think writing video games is more a question of 'what if' rather than one of 'daily schedules'. The whole process is the total opposite to that which the 'serious, professional' programmers work by. Their products have a very clear design spec and the plan doesn't really change a great deal, also each new product is often just an upgraded and embellished version of the previous one. Video games have NO clear goal in mind, the basic outline, story and map designs can be drawn up at the beginning but usually major and I mean major changes occur forcing pages of code to be tweaked or totally scrapped in the name of playability. Each game should atleast attempt to break new ground, to present something novel which the player has seen before. There can sometimes be alot of 'play it by ear' design and programming which help to shape a game beyond the predictable clone status. This gives many managers ulcers as they are unable to control the 'talent' of their employees, but why should the programmers be the only ones to sweat blood and tears?
1: So Long, Fairwell..
One of the most interesting things about programming 3d it that there is still so much yet to be done before the all time ultimate, mega-optimum method is found. Many of the well established algorithms and techniques are useful in themselves and can often be applied to other things but there are still many holes yet to be plugged. Like the Sutherland-Cohen line clipping using outcodes, under certain situations it can not reject or accept certain slopes which must be clipped and retested, so there is room for improvement here. Even things like the Bresenham line drawing algorithm which on the face of it may appear to be the ultimate scan converting method can in fact be improved using a "run-length slice" method something which is almost indentical to an optimization that I had worked out 4 years before I knew what it was called (except mine doesn't require a division, heh heh). I think even the God-like Mr. Bresenham had figured this out as well.
Sometimes "You have boldy followed where someone else has gone before...."
So okay, you might not be a pioneer in the field but perhaps your fresh, new approach might yield a few more tricks here and there. Sometimes after looking at a piece of code for too long you can start to get 'snow blind' and miss a trick here or here, so take a break or better still ask a fellow coder to take a pew or two they might suggest an obvious trick that you overlooked. If you think you have found the ultimate algorithm then take a long look at some of your old 'optimized' code. This will usually make you say "Yuck! What the hell was I doing back then? If I knew then what I know now...." Yep, the moral of the story is..
Today's optimization is tomorrow's slug...
This is too true, just look at the various CLK-timings of 8086 CPUs compared to many of today's "faster" CPUs and note how some instructions have actually got slower ! And on this happy note I will say .....
"That's All Folks!"
the end.